In contrast to circuit-switched networks, traditional IP-networks employ a connectionless packet-switching paradigm which uses neither call admission control nor per-call state within the network. Each packet is simply routed to its destination hop-by-hop according to the globally unique IP destination address contained within the IP header. Individual data flows do not receive a dedicated bandwidth, and the available bandwidth is shared among all traffic. When the aggregate packet flow sent to an intermediate node output port is greater than the output link rate, packets must be queued in the output buffer which causes delay. Furthermore, in periods of congestion, the output buffer may overflow and packets will be lost.
Although traditional packet-switched data networks such as X.25 and IP/Internet can achieve high bandwidths utilisation, they cannot simultaneously offer sufficient QoS (Quality of Service) support for real-time traffic such as voice. This is unlike newer packet-switched technologies such as ATM and Frame Relay which are able to offer both high utilisation and real-time QoS support simultaneously in an environment containing both real-time and non-real-time traffic. These dual goals of QoS support and efficiency can also be provided in an IP network if a reservation protocol such as RSVP (ReSerVation setup Protocol) is used, although firm QoS guaranties can only be offered provided each intermediate router supports RSVP. Before the network can offer a bandwidth guarantee, or reservation, to a specific data flow, admission control must ensure that the guarantee can be met i.e. sufficient resources exist in the network. Otherwise, the network will not pledge the guarantee to the user.
The end-to-end QoS available to users of a packet-switched network will be determined by two components. First, the amount of distortion introduced by the network in terms of packet delay, delay variation and packet loss. Second, the degree to which this network-induced distortion can be removed, or compensated for, at the receiving terminal, a process commonly referred to as terminal conditioning. Terminal conditioning may incorporate such processes as the removal of jitter (delay variation among packets) to reconstruct the original timing relationship. between packets at the receiver. In addition, it may allow the receiver to recover lost packets in cases where the sender employs some kind of robust encoding schemes that introduce redundancy among data packets transmitted.
As already mentioned above, one of the approaches that in principle might be used to guarantee, or at least maximise, the network layer QoS received by real-time traffic such as voice in multimedia packet-switched environment concerns reserving resources (bandwidths, buffer space) in the intermediate routers/switches for specific data flows and is a method used by both ATM (Asynchronous Transfer Mode) and IP/RSVP. The RSVP can be used by receiver and nodes to request end-to-end reservations in accordance with the IETF (Internet Engineering Task Force) integrated services models. RSVP is specified in the specification RFC 2205. In particular, RSVP is not a routing protocol, but is merely used to reserve resources along the existing route set up by whichever underlying routing protocol is in place. A communication session is identified by a combination of destination address, transport layer protocol type and destination port number. It is important to note that each RSVP operation only applies to packets of a particular session and as such every RSVP message must include details of the session to which it applies. RSVP messages can be transported “raw” within IP datagrams using protocol number 46 although hosts with this raw I/O capability may first encapsulate the RSVP messages within a UDP header.
In mobile networks such as UMTS or GPRS networks, sufficient end-to-end QoS for a call must be set up. To achieve this, a PDP (Packet Data Protocol) context with sufficient QoS is activated to transfer the voice traffic. Thus, the QoS requirements of a call must be known by both endpoints. By knowing the QoS requirements, the endpoints can set up the sufficient QoS with mechanisms depending on the environment of the endpoints. In combined networks where the mobile network is connected to an IP network, the RSVP has been proposed to signal the QoS requirements between the networks. However, the RSVP causes unnecessary signaling to transfer the QoS requirements. Moreover, it is questionable whether the RSVP is scaleable enough to be used on a per-call basis.